Suplemento mensual dedicado a la imagen rintética. Número 1 


Rendenmantia 


La Portada. La batalla prometida 
Primeros pasos con POV (II) 


Foro del Lector. Selección de trabajos y preguntas 
Las escenas de la batalla y sus ficheros 
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Cómo... 


Empezar con POV (parte 11 | 


A pesar de que «POV» tiene una presencia casi constante en 
Rendermanía, cada vez es mayor el número de lectores que declaran en 
sus cartas no entender muchos de los artículos dedicados a este 
programa, e incluso hemos recibido misivas donde se nos pregunta 
“¿qué es POV?”. Esta aparente paradoja tiene una fácil explicación. 

Hace ya casi año y medio explicamos los conceptos básicos de este 
raytracer y desde entonces no hemos vuelto a hablar de ellos, con lo cual 
los lectores más recientes no pueden seguir los artículos más complejos. 
Por esta razón, este mes continuaremos repasando los temas básicos 


como preludio a otros asuntos más complejos como la creación de 


texturas procedurales o la animación. 


ay que aclarar, sin 
embargo. que los 
presentes artículos 
no van a ser una 
repetición del mi- 


crocurso que dedi- 
camos a «POV» en los números 0 y 1 
de Rendermanía. En aquella ocasión 
nos centramos en gran medida en las 
sentencias de creación de objetos del 
lenguaje escénico de «POV» y en có- 
mo modelar con ellas. Esta vez, por 
el contrario, obviaremos casi toda es- 
ta parte, asumiendo que la mayoría de 
los usuarios van a trabajar con mode- 


los importados construidos desde mo- 


deladores gráficos. Así pues estudia- 


desde otros modeladores y exportar- 
los a «POV», desde donde los mani- 


pularemos para crear la escena utili- 
zando el lenguaje escénico. Esto 
resulta menos interactivo que realizar 


todo el trabajo desde un modelador 
¿visual como «Rhino» o «3D Studio», 


pero también presenta importantes 


osib 


ar Ese cilla aún— trabajando con otros 


es que de esta manera no estaríamos 


odeladores (como Rhino), el caso 


aprovechando las posibilidades de 
«POV». Lo ideal es crear los objetos 


Figura 1 


declare colorpiel=texture( 
declare vari=rand(R) 
pigment [ color rgb <.10, 1-(vari/4), .20> ] 
) 


de POV. Com 
procesó el arc 


«3D Studio» y creó d 
«POV». La malla con la ; 
vaca se guardó en el arch 


declare head=object[ffinclude “head1.inc”)] // la cabeza del orco 
ttdeclare torax=object(+ttinclude “torax.inc”) // su tórax 
ttdeclare brazo_derecho=object[ffinclude “brazod.inc”) // su brazo derecho 


y otros datos como el color de la vaca, 
la posición y orientación de la cámara 
y la iluminación se almacenaron en 
// la unión siguiente define al modelo completo del orco 

unioní 

objectíhead rotate y*45) // la cabeza rota 45 grados 
objectítorax ) 

object(cinturon pigment([MarronClaro)) 


vaca.pov. Por ello puede decirse que, 
más que un traductor de objetos, 
3ds2pov es un traductor de escenas, 
ya que, salvo por la aplicación de los 
bitmaps, esta utilidad traduce todos 
los elementos de la escena original de 
«3D Studio» al formato de «POV». Sin 
embargo, aunque gracias a 3ds2pov 


texture[colorpiel) 
translate <Xpos,35,Zpos> // todo el conjunto se traslada 


ca a )  // aquí termina la unión 
podríamos limitarnos después, sin ha- 


cer nada más, a ordenar el render des- 


de «POV» y aunque esto mismo es 


Esto generaba una vaca en la posi- 
ción definida por la malla guardada en 
el fichero vaca.inc. Para poder crear 
una segunda vaca O para manipular a 
una única vaca había que utilizar una 
sentencia object como la que sigue: 

object([ttinclude “vaca.inc” transla- 
te<344,0,400>) 

Con la sentencia object se crea una 
especie de contenedor definido por los 
corchetes. Así, las operaciones de 
transformación espacial que se definan 
dentro de estos corchetes afectarán 
únicamente al objeto contenido por 
ellos. Este detalle —tan parecido a los 
bloques de C— es una parte fundamen- 
tal de la filosofía de POV y habremos 
de tenerlo en cuenta en la manipula- 
ción de cualquier objeto compuesto 
por otros más simples (como es el ca- 
so del orco o del guerrero humano). 
Examinemos ahora el ejemplo de la 
Figura 1 (en la página anterior). 

En este ejemplo podemos compro- 
bar muchos de los detalles que con- 
forman la filosofía de «POV». Se trata 
de un extracto de un fichero para crear 
una figura antropomórfica. La prime- 
ra sentencia es un ttdeclare con el que 
se define el identificador “colorpiel” 
como una textura (que luego podría 


Cóm0O... 


tdeclare Here=<1,2,3> 

ttdeclare Count=0 

union [ 

object [ Rod translate Here*Count ] 
Hdeclare Count=Count+1 

object [ Rod translate Here*Count ] 
ttdeclare Count=Count+1 

object [ Rod translate Here*Count ] 


ser aplicada a un objeto). Después se 
usan tres ttdeclares para definir tres 
objetos llamados “head”, “torax” y 
“brazo_derecho”. Así pues, como po- 
déis ver, podemos usar la sentencia 
tídeclare no sólo para asignar valores 
a variables sino también para declarar 
nuevas texturas y objetos. La sintaxis 
para declarar un objeto es: 

tídeclare identificador=object [sen- 
tencias de definición] 

Luego, para utilizar lo declarado, 
tendremos que usar una línea como: 

object[ identificador sentencias] 

Con ttdeclare el objeto definido po- 
drá ser invocado cuantas veces quera- 
mos en la escena usando sentencias 
object. Seguramente el lector se pre- 
guntará por qué tenemos que moles- 
tarnos en hacer esto cuando podría- 
mos escribir algo como: 


Figura 2 


// initialize Count 


// re-declare inside union 


// re-declare inside union 


object[tftinclude “objeto.inc” sen- 
rencias) 
...cada vez que deseáramos situar un 
objeto (guardado en otro fichero) en 
la escena. Para responder a esto ima- 
ginad que queremos situar 200 orcos 
en nuestra escena (por ejemplo para 
una batalla). Con Hinclude, «POV>» 
tendría que leer 200 veces el fichero 
objeto.inc, lo cual sería horriblemente 
lento (sobre todo si objeto.inc es un 
modelo poligonal complejo). En cam- 
bio usando Hdeclare «POV» sólo lee- 
ría el fichero una vez, guardaría un 
modelo en memoria asignándolo al 
identificador, y lo emplearía cada vez 
que el identificador fuese invocado 
con object. Es de suponer que la can- 
tidad total de RAM empleada será si- 
milar en ambos casos pero tfdeclare es 
más cómodo y más versátil (como ve- 


> 
se 


Las texturas procedurales son tridimensionales, como puede apreciarse en estas imágenes de ejemplo. 


remos mas adelante). Aunque ttdecla- 
re nos permite declarar mas cosas 
además de variables, objetos y textu- 
ras, por el momento nos contentare- 
mos con esto. 

Un identificador puede tener hasta 
40 caracteres y puede emplear letras 
y números (aunque no debe comenzar 
con un número). También es impor- 
tante recordar que «POV» diferencia 
entre mayúsculas y minúsculas por lo 
que el identificador “Yu Yu” no es lo 
mismo que “yuyu” y también habre- 
mos de tener cuidado de no usar co- 
mo identificador ninguna palabra re- 
servada del lenguaje escénico como 
sphere, box u otras similares (consul- 
tad la lista en povray.doc, en el apar- 
tado “Identifiers and Keywords”). 
Hay que tener cuidado con estos dos 
últimos detalles. 

Las declaraciones pueden colocarse 
en cualquier punto de los ficheros, in- 
cluso dentro de otras sentencias. En la 
Figura 2 tenemos un ejemplo tomado 
de povray.doc 

El trabajo con las variables se basa 
en la facultad que ofrece ttdeclare de 
emplear un valor asignado anterior- 
mente como parte de una nueva decla- 


ración. Sin embargo, hay un caso don- 
de esto no funcionará: si intentamos 
redifinir un identificador como algo 
distinto obtendremos un error en el 
parsing. Así, si por ejemplo hemos 
definido “hroki” como una textura e 
intentamos redefinirla después como 
un Objeto, obtendremos un error y lo 
mismo sucederá si definimos un iden- 
tificador como un valor e intentamos 
declararlo luego como un vector. 


Uniones 

Pero continuemos con el ejemplo de 
la Figura 1. En él veremos que el ter- 
cer bloque de sentencias comienza 
con la palabra unión. Esta sentencia 
se utiliza para crear objetos compues- 
tos por otros más simples. Su forma 
de uso es similar al de object, pero 
con la diferencia de que podemos me- 
ter varios objetos dentro del bloque 
delimitado por los corchetes. Estos 
objetos no tienen por qué ser objetos 
simples ya que una unión puede estar 
compuesta también por otras uniones. 
La utilidad de las uniones radica en 
que, aefectos prácticos, «POV» trata- 
rá como un objeto único todo lo que 
se halle dentro de los corchetes de una 


de estas sentencias. Esto es muy útil 
porque los modelos complejos rara- 
mente suelen estar compuestos por 
una única pieza. En el caso de nuestro 
orco, por ejemplo, éste está compuesto 
por piezas como los brazos, las pier- 
nas, la cabeza, etc, cuya posición y 
orientación nos puede interesar alterar 
individualmente dentro del conjunto 
del modelo. Veamos como funciona: 
la primera sentencia que encontramos 
dentro del bloque de la unión es 

object[head rotate y*45) 

Esta sentencia indica a «POV» que 
el objeto head ya declarado antes es 
parte de la unión. Al no haber ninguna 
orden translate dentro del bloque de 
este object, «POV» situará a head en 
la escena en la misma posición en que 
este objeto se halla definido. (Head, 
como otros objetos del orco, es un ob- 
jeto poligonal y su posición inicial 
viene dada por los valores asignados a 
los vértices de su malla). Lo que sí te- 
nemos aquí es una transformación ro- 
tate que hará girar la cabeza 45 gra- 
dos. Como la sentencia rotate está 
encerrada dentro del bloque contene- 
dor de head, esta transformación es- 
pacial sólo afectará a la cabeza, sien- 
do ignorada por el resto de los objetos 
miembros de la unión. 

Esta regla de aislamiento de los blo- 
ques es simple pero esencial y tene- 
mos otro ejemplo de su funciona- 
miento en el tercer miembro de la 
unión donde se asigna el color “Ma- 
rronClaro” al objeto “cinturón”. (La 
sentencia pigment especifica el color 
de un objeto y normalmente suele ser 
parte de la definición de una textura 
pero, si no vamos a definir otras pro- 
piedades para la textura, podemos uti- 
lizar pigment fuera de texture). Puesto 


que la sentencia pigment está dentro 


del bloque de “cinturón”, el color in- 
dicado sólo se aplicará sobre este ob- 
jeto y no sobre los anteriores. 

Por último fijaos en las dos últimas 
sentencias escritas dentro de la unión. 
Estas sentencias no agregan nuevos 
miembros a la unión. La primera es 

texture(colorpiel] 
que aplica una textura ya declarada an- 
teriormente. Pero, ¿dónde se aplica es- 
ta textura? Siguiendo las reglas de los 
corchetes podemos adivinar que se 
aplica dentro de la unión, es decir, so- 
bre todos los miembros de é g 
¿Qué sucede con el.objeto “cinturón”? 
En este caso concreto «PON 


£s 


asignado una textura a “ci 


detalles acerca 
construcción de tex 
mos que las texturas “norma 
«POV» se definen con sentencias que 
se agrupan en tres apartados diferen- 
ciados: la pigmentación (pigment), las 
sentencias que perturban las normales 
(normal) y las que definen el acabado 
de la superficie (finish). Para cada uno 
de estos apartados «POV» tiene ya 
asignados unos valores por defecto 
(que pueden cambiarse), de manera 
que podemos ahorrarnos escribir la 
declaración completa de una textura 
cuando estamos creando una nueva. 
Así, en lugar de escribir algo como lo 
que aparece en la Figura 3... 


— y] texturel 


...podemos limitarnos a escribir, por ya fue incluido en el número 14 de 


ejemplo: Rendermanía: 
pigment( sentencias que afectan al Fijaos en el caso del objeto manod 
color ] (mano derecha). Sobre este objeto se 
Pero cuando «POV» encuentra una aplican primero las transformaciones 
línea como la anterior. lo que hace es escritas dentro de la unión de la que 
aplicar una textura completa usando los forma parte. Después se le aplican las 


transformaciones de la unión de ma- 


valores por defecto para los otros apar- 


tados (lo mismo sucede con normal y yor nivel (el antebrazo) de la que for- 


finish). Por esta razón, en el ejemplo ma parte la unión de la que es miem- 
anterior la asignación del pigmento bro. Y por último se efectúan las 
“MarrónClaro” provoca la asignación transformaciones de la unión princi- 


completa de una textura de manera que 


Ar? 


pal que es el brazo. Este ejemplo —cu- 


se ig- yo correcto funcionamiento quedó 


4 demostrado con los orcos del número 


ación espacial. Esta transfo 
se aplicará sin excepciones sobre to- 


dos los miembros de la unión. ¿Qué 
ocurre entonces, os preguntaréis, con 
el miembro head que tiene escrita una 


transformación dentro de su bloque? 


En este caso se aplicarán las dos. Pri 
mero «POV» efectuará la transfórma- 4 


ción particular de head, haciendo rot: dada a la mano 


pero ésta, ade- 


to 


más, Obedecerá 


pigment[ sentencias que afectan al color ) después prime- 


normal[ sentencias que afectan a las normales ) 
finish sentencias que afectan al acabado ) 


ro a las trans- 
formaciones 
) escritas para el 


Figura 3 antebrazo y 


luego a las se- 
ñaladas para el 
la cabeza del orco y luego la unión brazo entero. Al llegar a este punto, 
completa (el orco) será trasladada a la quizá los pov-adeptos más novatos se 
posición resultante al aplicar la tras- sientan ya con fuerzas para afrontar el 
lación global. (Y este será el resultado artículo dedicado a este tema en el 
que obtendremos cuando la escena es- Rendermanía 14 pero, como este ca- 
té lista). Esta regla es idéntica para so es un poco complejo, os recomen- 
otros casos más complejos. Recorde- damos que practiquéis con ejemplos 


mos un ejemplo muy ilustrativo que más simples. 


Proa A A, 


y 


La sentencia unión es muy emplea- 
da también por las utilidades de tra- 
ducción, que la utilizan para agrupar 
listas de triángulos de manera que se 
pueda asignar fácilmente texturas O 
transformaciones a los objetos forma- 
dos por estas mallas de triángulos. 
También hay que decir que unión fue 
diseñada en principio como parte de 
la filosofía de modelado de «POV», la 
cual se apoya grandemente en las ope- 
raciones booleanas. Pero por ahora no 
vamos a entrar en ello porque dichas 
operaciones no funcionan con los ob- 
jetos poligonales importados. 


Algo sobre colores y texturas 

Para poder crear una escena en 
«POV» diferente a una imagen abso- 
lutamente negra no basta con crear o 
cargar objetos en el pov-universo y 
encender una fuente de luz dentro de 
éste (además, claro está, de situar y 


orientar una cámara). También hay 
que asignar texturas a los objetos 
puesto que de lo contrario no podre- 
mos verlos aunque estén ante nuestras 
narices. Por ahora no vamos a estudiar 
las sentencias que nos permiten crear 
nuestras propias texturas y vamos a li- 
mitarnos a señalar que «POV» ya trae 
incorporada una gran 


//brazo derecho 
unioní 
unionfobject(antebd) 
objectímunned) 


librería de texturas 
para que podamos 
crear objetos con apa- 
riencia de madera, 


agua, piedra, cristal, 


//la mano y su arma cogen tambien el giro del antebrazo 
unionfobjectímanod) objectfarma) 
translate<39.5,-75,-2.5> 
rotate <rmanodX, rmanodY, rmanodZ> 
translate<-39.5,75,2.5> 
) 
translate<38,-104,-12> 
rotate <rantebdX, rantebdY, rantebdZ> 
translate<-38,104,12> 
) 
object(brazod) 
translate<25,-136,-9> 
rotate <rbrazodX, rbrazodY, rbrazodZ> 
translate<-25,136,9> 


Figura 4 


metales, etc. Estas 
texturas predefini- 
das están almacena- 
das en los ficheros 
woods,inc, stones.inc, 
metals.inc, glass.inc y 
otros que encontrare- 
mos en el subdirecto- 
rio llamado “include”, 
dentro del directorio 
donde tengamos a 
«POV». Estas textu- 
ras están creadas con 
tídeclare y asignadas 
a identificadores, 


por lo que para utilizarlas nos bastará 
con emplear la sentencia texture escrl- 
biendo dentro el nombre del identifi- 
cador. En ciertos casos, no obstante, 
puede ser necesario algo más. Si por 
ejemplo estamos asignando una textu- 
ra de madera a un objeto, los resulta- 
dos dependerán en gran medida de la 
escala del objeto con respecto a la tex- 
tura. Así. si el objeto resulta demasia- 
do grande con respecto a la escala a la 
que se han definido los detalles de la 
textura, puede suceder que no perci- 
bamos dichos detalles al observar al 
objeto. Para remediar esto bastará con 
escribir una sentencia de escalación 
dentro del bloque de la textura. Así, 
por ejemplo, la sentencia: 

object[head texture[T_Wood28 
scale<2,2,2>) ] 

hace que la textura se aplique a una 
escala dos veces mayor de lo normal 
sobre el objeto head. Naturalmente es- 
to es posible sólo porque, siguiendo 
las reglas del ámbito de los bloques. 
la operación de escala afecta sólo a la 
textura y no al objeto. Éste conservará 
el tamaño que tuviese pero los deta- 
lles de la textura pasarán a ser dos ve- 


ces más grandes. Quizá, observando 
la sentencia os preguntéis por qué he- 
mos hecho que la escala se efectúe en 
los tres ejes y la respuesta es que 
T_Wood28 es una textura procedural 
normal de «POV» (definida en woods.inc 
con sentencias normales del lenguaje 
escénico, como las demás). Esto sig- 
nifica que, como todas las demás tex- 
turas algorítmicas de nuestro amado 
raytracer, ocupa un volumen infinito 
en todas direcciones. 

Esto quizá parezca raro a los render- 
maníacos que sólo hayan trabajado 
con las típicas texturas tipo bitmap, 
pero es así. En «POV» las texturas 
procedurales son como volúmenes tri- 
dimensionales que ocupan todo el 
universo espacial del programa. 
Cuando se declara un objeto dado en 
una posición espacial y se le asigna 
una de estas texturas, el objeto queda 


CÓMO... 


“impregnado” con el dibujo 3D que la 
textura tenga en esa posición. Para 
comprenderlo echad un vistazo a las 
dos escenitas de prueba. En la primera 
de ellas tenemos una esfera con una tex- 
tura de madera tomada de woods.inc 
y en la siguiente tenemos a la misma 
esfera a la que se le ha cortado la mi- 
tad superior. El interior de la esfera 
también tiene la textura aplicada. 
(otros programas como «Imagine» o 
«3D Studio» también tienen sus pro- 
pias texturas procedurales pero la 
gente casi nunca las usa, prefiriendo 
emplear bitmaps). 

A estas alturas os habréis dado 
cuenta de que tendremos que escribir 
una sentencia Hinclude para cargar el 
fichero woods.inc antes de referenciar 
ala textura T_Wood28. Si no lo hace- 
mos así, «POV» nos dará un mensaje 
de error y la escena no se generará. 


(La práctica usual en estos casos es 
colocar todos los +fincludes al princi- 
pio del fichero escénico). Pero además 
de esto hay que hacer una cosa más, 
hemos de indicarle a «POV>» dónde es- 
tán los ficheros. Por defecto, la orden 
ttinclude busca los archivos que debe 
cargar en el directorio en curso pero 
puede suceder, como ocurre con los fi- 
cheros de texturas de «POV», que los 
archivos referenciados estén en otra 
parte. En estos casos «POV» seguirá 
buscando en los directorios que le ha- 
yamos indicado con el comando “L” 
de la línea de órdenes (más adelante 
veremos cómo funciona). 

Por otro lado, «POV» también tie- 
ne definida una buena lista de colores 
que hallaréis declarados en colors.inc. 
Para usarlos únicamente tendremos 
que escribir el identificador del color 
dentro de la sentencia pigment. Pero, 


En esta escena hemos empleado el mismo fichero que se utilizó para la imagen de portada de Rendermanía 14. 


por supuesto, no tenemos por qué res- : 
tringirnos al uso de esta lista de colo- E 
res. Podemos crear nuestros propios . 
colores usando sentencias como: E 
pigment(color rgb<1,0,0>) . 
o como: : 
pigment(rgb<1,0,0>) E 
En ambos casos se crea un pigmen- E 
to rojo gracias a la sentencia RGB. la : 
cual emplea valores que pueden osci- : 
lar de O a 1 para asignar intensidades ¿ 


a los componentes de rojo, verde y 


El mismo valor de semilla genera idéntica postura para ambos 
personajes, como podéis apreciar en estas imágenes. 


de su librería. Estos archivos están lo- ¿  +W indica la resolución horizontal 
calizables en diversos subdirectorios ¿ de la imagen a generar. 


del directorio texsamps (el cual, claro : +H indica la resolución vertical. 
¿ está, se halla dentro del directorio raíz : +D se usa para activar la visualiza- 
: donde hayáis metido «POV»). E ción del modo gráfico mediante el 
¿ : cual podremos ir viendo como «POV» 
: Algunas órdenes de la linea E genera las imágenes línea a línea. Este 
¿ de comandos . comando acepta dos parámetros que 
¿ Para generar las imágenes correspon- - se especifican con letras que deben co- 
E dientes a los archivos mencionados an- E locarse juntas. La primera sirve para 
. tes O para crear alguna de las muchas : indicar el tipo de tarjeta gráfica dispo- 
¿ escenas de ejemplo que incluye «POV», E nible o para ordenar el empleo del es- 
E más valdrá que hablemos de las órde- E tándar VESA (letra “G”) y la segunda 
Cada valor aleatorio genera una a nes de línea más utilizadas que admite E señala el tipo de paleta. Normalmente 


variación en la postura básica. la versión MS-DOS de «POV». Esto: 


solemos utilizar las letras H (Hicolor) 


añ, o T (Truecolor). A veces puede conve- 


la máxima posible. agen pulsando una tecla. 


tos componentes se complem tumpimos la creación de 

ra producir todos los color 

Así, por ej “RGB<T,0:48; 
RGB<I1.1.1>” 


remos que «POV +0 se emplea vez que ha € ión de 


cheros de ejemp el nombre que yv; la imagen. Seu 


sultado visual. qu cen las ti salida. imágenes. 


Xx 


á 
Ana 


camera (location <5900, 195, 0> 
direction <0.0, 0.0, 1> 
up <0.0, 1.0, 0.0> 
night <.72,0.0, 0.0> 
look_at <0,70.5,0> 

// orthographic 

) 


Figura 5 


+V Cuando hemos de desconectar la 


salida de vídeo es útil emplear +v para 
que «POV» vaya imprimiendo el nú- 
mero de línea con el que está trabajan- 
do en cada momento para hacernos una 
idea del tiempo que queda de render. 

+A Activa el antialias. Normalmen- 
te suele añadirse un valor que indica 
la fuerza del antialias (el valor por de- 
fecto es 0). Esto se usa para suavizar 
la apariencia escalonada que tienen 
las líneas diagonales en la imagen. 

+L Con esta opción podremos in- 
cluir una ruta al directorio donde ten- 
gamos ficheros .inc a los que vayamos 
a referenciar con ttinclude desde el fi- 
chero escénico que se vaya a procesar. 

+B Cada vez que se termina una lí- 
nea «POV» hace una grabación a dis- 
co a menos que usemos +B para redu- 
cir el número de accesos al disco 
duro. Junto a +B añadiremos un valor 
que será el número de Kbytes que ten- 
drá el buffer de grabación. La pega de 
esto es que si se va la luz o sucede un 
desastre habremos perdido todo lo 
que haya en el buffer. 

Por último adjuntamos aquí la línea 
de órdenes que solemos utilizar (den- 
tro de un fichero Bat). 

povray +ibatalla.pov +0batalla.tga 
+dGH +x -v +p +w800 +h600 +a 
+b192 +Ic:ipov302tinclude 
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Cóm0O... 


Entre otras cosas, esta línea hará 
que «POV» genere el archivo bata- 
lla.tga a partir del fichero .pov del 
mismo nombre. Se activará la visua- 
lización usando el estándar VESA y 
Hicolor, se desactivará la estadística 
de líneas (con -v. esto es preciso si la 
visualización está activada), se creará 
un buffer de grabación de 192 Kbytes 
y se indica con +L una ruta para bus- 
car los archivos .inc. También se em- 
plea el antialias estándar. 


La cámara 

La cámara de POV es similar a la de 
otros programas de imagen sintética, 
es decir, una cámara no visible que 
POV emplea para tomar una foto del 
universo virtual descrito en el archivo 
escénico suministrado como entrada 
al programa. Por esta razón todos los 
ficheros escénicos deben incluir una 
descripción de una cámara válida uti- 
lizando las sentencias reservadas para 
ello en el lenguaje de POV. De lo con- 
trario, y al igual que sucederá si no hay 
objetos o fuentes de luz definidas en la 
escena, no obtendremos otra cosa que 
una imagen con un fondo negro. 

Por supuesto. podríamos evitarnos 
el estudio del manejo de la pov-cáma- 
ra si nos limitásemos a emplear pro- 
gramas como «Rhino» o herramientas 
de traducción como 3ds2pov (sin tra- 
bajar la escena después desde POV), 
ya que, recordemos, estos programas 
graban en el fichero escénico expor- 
tado una cámara equivalente a la em- 
pleada desde «Rhino» o «3D Studio». 
Pero si verdaderamente deseamos uti- 
lizar las capacidades de POV nos ve- 
remos obligados a colocar la cámara 
desde el lenguaje escénico. Esta tarea 
puede ser, no nos engañemos, bastan- 


El caballero emplea piezas 
Intercambiables. 


te trabajosa e ingrata comparada con 
el rápido manejo de la cámara que nos 
ofrece cualquier buen modelador. En 
efecto, a menudo nos resultará difícil 
predecir la imagen que se obtendrá de 
la colocación de una cámara determi- 
nada o el campo visual que abarcará 
ésta, y ello nos obligará a realizar bas- 
tantes pruebas. 

Las sentencias que definen la cáma- 
ra suelen ir colocadas casi al principio 
del fichero escénico, después de los 
tfincludes, aunque pueden ser escritas 
en cualquier otra parte del archivo, En 
la Figura 5 tenemos la cámara emple- 
ada para la escena de la portada. 

Las sentencias que definen a la cá- 
mara han de seguir a la sentencia “ca- 


ttinclude “colors.inc” 

camera [ 
location <0, O, O> 
direction <0,0 ,1> 
up <0.O, 1.0, 0.0> 
right <1.33,0.0, 0.0> 


light_source (<0,0,0> color White) 


sphere[<0,0,5>,1 pigment(Green)) 
sphere[<0,0,-5>,1 pigment(Blue)) 


a 


En la imagen se aprecia el momento de ajustar las dimensiones del 


caballero a las dei orco. 


mera” y estar englobadas por corche- 
tes, aunque no tienen por qué seguir 
el mismo orden que aparece en esta fi- 
gura. La primera de ellas. “location”. 
se utiliza para indicar —dando valores 
para los ejes X, Y y Z- la posición es- 
pacial de la cámara. Luego, para en- 
focar a ésta, deberemos emplear la 
sentencia “Look_at” (mirar a), con la 
que indicaremos el punto espacial ha- 
cia el que queremos apuntar la cáma- 
ra. Al hallar esta sentencia. POV hará 
girar la cámara a la derecha o la iz- 
quierda y la inclinará hasta que el 
punto a enfocar quede apuntado por 
la cámara. 

Llegados aquí se hace necesario ex- 
plicar un par de puntos. La cámara no 
es un objeto sólido ni tiene dimensio- 
nes, pero debemos imaginar que, co- 
mo en el caso de las cámaras reales, 
tiene una lente a la que llamaremos 
“ventana de visión”. Esta ventana de 
visión tiene forma rectangular y sus 
características son controladas por las 
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sentencias “direction”, “up” y “right”, 


las cuales controlan también el campo 


visual que abarca la mencionada ven- 
tana de visión. Direction define la di- 
rección inicial hacia la que apunta la 
cámara. Así, por ejemplo, la senten- 
cia direction “<0.0, 0.0, 1>” del ejem- 
plo significa que la cámara inicial- 
mente está mirando en la dirección 
+Z. El valor 1 también significa que 
la lente se encuentra a una unidad de 
distancia de la posición base de la cá- 
mara y esto determina —junto con el 
valor de up- el tamaño de la ventana 
de visión. 

Para comprenderlo dibujad en una 
hoja un punto para representar la po- 
sición base de la cámara y también 
una línea vertical a la derecha del 
punto anterior (la línea ha de estar 
centrada verticalmente con respecto a 
dicho punto). Si ahora trazáis dos lí- 
neas que conecten el punto con los 
dos extremos de la línea vertical po- 
dréis visualizar el perfil de una cáma- 
ra típica de POV, donde la apertura 
del campo de visión depende de la 
distancia de la ventana de visión (la 
línea) con respecto a la posición de la 


cámara (el punto). Observaréis que si 
arrastráis la línea vertical a la derecha 
las dos líneas diagonales (que repre- 
sentan el campo de visión de la cáma- 
ra) formarán un ángulo menor entre sí. 
Traduciendo este ejemplo a POV, sig- 
nifica que un valor corto de direction 
implica un campo de visión mayor y 
un valor largo lo contrario. Fijaos en 
la Figura 6. 

En el ejemplo no hay sentencia look_at. 
La cámara mira en la dirección +2 de ma- 
nera que, al renderizar la escena, con- 
templaremos una esfera verde (green) 
en el centro de la escena. Aquí la len- 
te de la cámara se encuentra a una 
unidad de distancia de la cámara. Si 
ahora cambiamos el 1 de direction por 
un 2 y volvemos a realizar la prueba 
la esfera será dos veces mayor. Esto 
se debe a que hemos alejado la venta- 
na de visión de la cámara reduciendo 
el campo de visión, lo cual se aprecia 
como un zoom realizado sobre la di- 
rección enfocada. (Si se sustituye el 1 
por -1 la cámara apuntará a -Z y vere- 
mos la esfera azul). 

En cuanto a las sentencias up y 
right, éstas controlan las proporciones 
de la ventana de visión, la orientación 
del sistema de coordenadas (right) y 
la dirección vertical de la ventana de 
visión (up). El valor 1.33 de right sig- 
nifica, por ejemplo, que la imagen va 
a ser un 1.33 más ancha que alta. Es 
decir, que vamos a ordenar con +w y 
+h una resolución como 640*480 ó 
800%600 por ejemplo. En cambio, pa- 
ra generar una imagen de 1024 de alto 
por 768 de alto, el valor de right debe- 
ría ser de .72. (Nota: raramente toca- 
mos up y solamente cambiamos right 
cuando vamos a lanzar escenas con 
distintos formatos. Es peligroso cam- 
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Hemos creado un nuevo soldado con Rhinoceros. 


biar right a negativo porque uno puede 
volverse loco si está acostumbrado al 
sistema “normal” de “mano izquierda” 
que utilizamos aquí. Casi siempre 
suele bastar con trastear con location 
y look_at. ¡Ojo! Poned siempre la 
sentencia look_at después de las de- 
más ya mencionadas). 


Tipos de cámara 

En el primer ejemplo había una sen- 
tencia llamada “orthographic” anula- 
da por un comentario. Esta sentencia 
cambiaba el tipo de perspectiva por 
defecto por otra en la que los rayos 
son paralelos. Este tipo de cámara sin 
perspectiva es muy útil cuando se 
quieren realizar pruebas de estimación 
de distancias o estamos estudiando las 
formas de un objeto y no queremos ser 
engañados por la perspectiva. 

Aparte de orthographic existen 
otros tipos de cámara como fisheye 
(ojo de pez), omnimax, panoramic y 
cylindrical. Para comprobar su fun- 
cionamiento sólo tenéis que incluir la 
palabra correspondiente al final de las 
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sentencias de la cámara. Y, por su- 
puesto, también podemos crear nues- 
tra propia cámara utilizando senten- 
cias como angle. 


Fuentes de luz 

Para concluir con la pequeña intro- 
ducción que estamos realizando sobre 
«POV» vamos a tratar brevemente el 
tema de la luz. 

«POV>» dispone de varios tipos de 
fuentes: ambientales, omnidirecciona- 
les. focos, cilíndricas y áreas de luz, 
y también cuenta con diversas posibi- 
lidades de control sobre estas fuentes. 
Sin embargo, nos limitaremos a ha- 
blar del tipo de fuente más sencilla y 
utilizada: la omnidireccional. El nom- 
bre de esta fuente se debe a que sus 
rayos parten en todas direcciones (co- 
mo en el caso del sol o de una bombi- 
lla). Veamos su formato: 


light_source [<0,0,0> color White] 


Esta sentencia crea una fuente de 
luz omnidireccional de color blanco 


en las coordenadas <0,0,0>. El forma- 
to de la sentencia es, pues, muy senci- 
llo. Primero incluimos la sentencia y 
dentro de los corchetes delimitadores 
colocamos, primero. las coordenadas 
de posición y luego el color de la 
fuente. Podemos indicar dicho color 
como en el caso anterior o emplean- 
do la sentencia “RGB” que ya vimos 
con los pigmentos: 


light_source (<0,0,0> color rgb<1.1.1>)] 


Normalmente basta con una o dos 
fuentes de este tipo para iluminar 
cualquier escena —ninguna de las imá- 
genes del presente número ha requeri- 
do más de dos fuentes—. Las fuentes 
de luz de «POV>» son puntuales, es de- 
cir, todos los rayos que emiten parten 
del mismo punto. Esto implica dos 
cosas: la primera que no son visibles 
(aunque existe una manera de crear 
objetos que simulan ser luminosos) y 
la segunda que las sombras que gene- 
ran tienen bordes excesivamente pre- 
cisos y que por ello resultan bastante 
irreales (lo cual se puede solucionar 
utilizando áreas de luz). 

Una buena iluminación es capital 
para lograr buenas e interesantes es- 
cenas. Si estáis trabajando sobre una 
imagen de tipo “a cielo abierto” lo 
mejor es situar las fuentes de luz a 
distancias astronómicas para que las 
sombras de todos los objetos tengan 
una orientación idéntica. También 
suele ser buena idea utilizar fuentes 
de colores distintos para crear algo de 
contraste y emplear áreas de luz si nos 
sobra tiempo (cada vez que sumermos 
una fuente a la escena estaremos au- 
mentando el tiempo de cálculo nece- 


sario para generarla). 


Y Ig Ñ 


La Portada 


¡La batalla 
de la gran llanura! 


El caballero se inclinó sobre la barandilla y miró hacia el suelo: a cientos 
de metros bajo sus pies se extendía un inmenso ejército. Arrugó la nariz y 
ordenó al oficial de navegación que pusiera rumbo al castillo. Con suerte 
el dirigible de exploración que mandaba llegaría al feudo a tiempo de 
prevenir al señor de aquella nueva invasión orca. Mientras el dirigible 
giraba lentamente, el caballero siguió observando con una sonrisa en los 
labios. ¡Sin duda se avecindaba una dura y estimulante batalla! 

espués de esperar 

durante meses el 

gran acontecimien- 


to, estamos prepa- 
rados para disfrutar 


de una batalla orco- 
humana digna de este nombre. Cien- 
tos de bestiales guerreros orcos han 
chocado contra las tropas humanas en 
un enfrentamiento largamente poster- 
gado. Ambos bandos han empleado al- 
gunas de las máquinas de guerra que 
enviasteis para apoyarles, y por ello la 
lucha ha sido verdaderamente feroz. A 
continuación os comentamos los deta- 
lles de este magno acontecimiento 


El origen de la batalla 
Todo empezó hace mucho tiempo 
con el número 1 de Rendermanía, 
cuando creamos unos lanceros bas- 
Ps: tante ridículos para poblar el castillo 
Una semliia diferente genera una portada distinta. virtual que ilustró aquel número. En 
ese mismo número un autor publicó 
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un orco de aspecto bastante feroz y 
nos comentó que sin duda su criaturi- 
lla virtual podría hacer trizas sin pro- 
blemas a los diminutos lanceros. Algo 
picados, decidimos reforzar a los lan- 
ceros con un cañón que apareció en el 
número 2 de Rendermanía, y a partir 
de aquí dio comienzo una inacabable 
carrera de armamentos. 

Así, comenzasteis a enviar modelos 
de máquinas de guerra para apoyar a 
uno u otro bando y pronto la idea de 
crear una portada con una batalla me- 
dieval fantástica como tema surgió sin 
remedio. Se pretendía crear una esce- 
na con cientos de guerreros donde 
apareciesen las catapultas y las demás 
máquinas de guerra enviadas por los 
lectores. 

Sin embargo, pasaron los meses y la 
batalla no parecía tomar forma en las 
páginas de Rendermanía. Finalmente, 
en el número 9 del suplemento, se pu- 
blicó una portada donde aparecían 
tres parejas de contendientes (¡sólo 
3!) peleándose sobre una superficie 
llena de libros. Esto fue decepcionan- 
te, por supuesto, pero al menos sirvió 
como base para estudiar los dos pro- 
blemas principales que presentaba el 
diseño de este tipo de escenas: 

* Los modelos eran mallas poligo- 
nales y cada personaje requería mu- 
cha RAM. 

* No se disponía de un modelo arti- 
culado de orco; entonces se empleó 
un zombie en su lugar. 

En el número 9 estos problemas no 
pudieron ser solucionados a tiempo 
pero no queriendo hacer esperar más a 
los lectores, se decidió emplear algu- 
nos de los modelos enviados para 
componer una portada. Al menos este 
número sirvió para comprobar lo sen- 
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cillo que resultaba crear 
posturas de modelos con 
«Imagine» y cómo expor- 
tar modelos poligonales a 
«POV». 

Sin embargo, pronto 
empezaron a resolverse 
los problemas que hacían 
imposible la ansiada bata- 
lla. Primero se creó un 
modelo articulable de or- 
co en el número 11 em- 
pleando «Rhinoceros» y 
luego, en el número 12, se 
añadieron un par de cabe- 
zas más de orco. Final- 
mente descubrimos el uso 
de mesh y poco tiempo 
después esta sentencia fue 
empleada para crear el 
ejército de orcos que apa- 
reció en el número 14 de 
Rendermanía. A partir de 
aquí sólo era cuestión de tiempo pre- 
parar nuestra primera batalla virtual. 


El bando humano 

El primer paso una vez resueltos los 
problemas principales era contar con 
modelos adecuados para la batalla. El 
modelo del orco podía servir a pesar de 
sus fallos de articulación pero no ocu- 
rría lo mismo con el viejo lancero. Éste 
resultaba ya algo simplón comparado 
con el orco y se necesitaba otro mode- 
lo de aspecto más realista. 

Por esta razón se ha creado un nuevo 
modelo de soldado que conserva, sin 
embargo, un cierto aire de familia con 
nuestro antiguo lancero, del que sólo 
hemos tomado las manos y el casco 
para el nuevo soldado. 

En principio la idea era crear una ar- 
madura completa pero pronto se optó 


por crear también piezas internas para 


el cuerpo. De esta manera se podían 
eliminar trozos de armadura y crear 
una mayor variación. Así, en las esce- 
nas que ilustran el presente número, 
hay soldados con y sin protección en 
las piernas (lo que se controla desde 
los ficheros escénicos gracias a una va- 
riable). Esto queda bastante bien por- 
que las piezas empleadas para el cuer- 
po del soldado han sido tomadas del 
cuerpo del orco. Naturalmente fue pre- 
ciso editar grupos de vértices para lo- 
grar que el soldado resultase menos 
musculoso que el orco. 

Pero la falta de tiempo hizo imposible 
llevar esta idea hasta sus últimas con- 
secuencias y por ello nuestro soldado 
no tiene cabeza bajo el casco ni puede 
quitarse aún las protecciones de los 
brazos al no estar recortado el peto. 


También hay que decir que nuestro 


soldado tiene fallos de articulación. Es- 
tos fallos son de difícil solución. Cuan- 
do, por ejemplo, el soldado levanta una 
pierna, ésta corta el faldón metálico de 
la armadura. Además, las hombreras 
pueden interseccionarse con el brazo si 
este se coloca en una posición excesi- 
vamente forzada, y lo mismu.sucede 
con la placa del codo. 

Al constatar esto, $e probó, en pri- 
mer lugar, que estos objetos rotasen 
acompañando el movimiento de las 
piezas de la armadura a que estaban 
unidas, pero.el.resultado era visual- 
mente muy confuso, por lo que se optó 
por dejarlas sin movimiento. 

Finalmente, con el fin de obtener al- 
go de variedad, se crearon varias pig- 
zas adicionales: un segundo escudo, un 
par de cascos más y otra hombrera. De 


esta manera se confiaba 
en obtener soldados bas- 
tante diferentes entre sí. 
Pero. como siempre. la 
falta de tiempo impidió 
disponer de todas las pie- 
zas que hubiesen sido ne- 
cesarias para que esta idea 
funcionase de verdad. Ha- 
bría sido conveniente dis- 
poner de un par de petos 
más, de varias piezas in- 
tercambiables para brazos 
y piernas, de un faldón di- 
ferente, etc. 


Preparación de las 
posturas 
En principio la idea era 
tomar nota desde «Imagi- 
ne» de los ángulos de ro- 
tación deseados para 
aplicarlos luego desde 
«POV», tal y como se hizo con las 
posturas creadas para el número 14. 
Pero pronto se comprobó que esto ya 
No era necesario. 

En efecto, después de unas cuantas 
pruebas la experiencia hizo posible 
escoger a mano los valores medios de 
rotación para las posturas de correr, 
golpear, defender y estar muerto. De 
esta manera, tan sólo fue preciso es- 
eribir los ficheros .pov e .inc necesa- 
rios. Aqui se comprobó que, como el 
esquema de articulaciones de ambos 
modelos era similar, los dos podían 
compartir los mismos ficheros .1nc de 
posturas, lo que permitió un significa- 
tivo ahorro de trabajo. 

Naturalmente esto fue posible por- 
que se emplearon los mismos fom- 
bres para las variables de rotación en 


orco.inc y guerrero.inc. Por esta ra- 


zÓn, ambos modelos pueden utilizar 
indistintamente los ficheros orcan- 
da.inc, correr. inc, golpear.inc y otros. 

Para quienes deseéis saber con más 
detalle cómo funciona esto os reco- 
mendamos leer el número 14 de Ren- 
dermanía, pues el proceso seguido es- 
te mes es el mismo. En resumen: 

* Se crean los modelos desde un 
modelador poligonal cualquiera. 

+ Se toma nota desde el mismo mo- 
delador de las coordenadas de los ejes 
de rotación de cada pieza. Estos valo- 
res serán empleados luego en los fi- 
cheros .pov que definen la jerarquía 
de los modelos. 

+ Se graba cada pieza del modelo m- 
dividualmente (exportándolas directa- 
mente a «POV» si el modelador lo 
permite o usando después una utilidad 
de traducción). 

* Se escriben primero los ficheros 
de jerarquía (como orco.inc y guerre- 
ro.inc) y luego los que guardan los va- 
lores medios de rotación para obtener 
las posturas. (Estos son correr.inc, 
golpear.imc, etc). Los ficheros de je- 
rarquía referencian a los ficheros .inc 
que guardan las mallas y hacen girar 
cada pieza o grupo de piezas según 
los valores de rotación suministrados 
por los archivos-postura. Además, los 
valores de rotación que se suministran 
a los archivos-jerarquía suelen ser 
siempre diferentes ya que los archi- 
vos-postura utilizan rangos aleatorios 
de libertad de movimiento para cada 
postura básica. De esta manera resulta 
posible obtener desde «POV» un nú- 
mero infinito de posturas a partir de 
un modelo almacenado en una única 
posición inicial. 

+ Después sé crean los ficheros :¿pov 
que definen las escenas y que em- 
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plean bucles +while con 
cientos de pasadas sobre los 
ficheros con las posturas (pri- 
mero) y los ficheros-jerarquía 
(después). Cada una de estas 
pasadas define un nuevo per- 
sonaje en la escena. 

Naturalmente todo esto 
ha sido posible gracias a las 
características de sentencias 
del lenguaje escénico corno 
tídeclare, Hinclude, twhile, 
Hif y otras. Y también al 
hecho de que cada objeto 
copia utiliza una ridícula 
cantidad de memoria en 
comparación a la que re- 
quiere el almacenamiento 
del modelo original al que 
se referencia con cada ob- 
jeto-mesh. 


La batalla y otras ideas 

Hemos preparado preferentemente 
escenas donde se ve a ambos ejércitos 
a punto de chocar. Aunque en princi- 
pio solamente se iba a preparar una 
portada, pronto quedó claro que la 
idea daba para mucho más y se optó 
por crear muchas más escenas. 

Esto resultaba tanto más preciso por 
cuanto era imposible aprovechar to- 
dos vuestros modelos en una única es- 
cena. De hecho, sólo hemos empleado 
algunos de vuestros primeros mode- 
los, ya que no había tiempo de prepa- 
rarlos a todos. 

Así, hemos empleado el dirigible 
humano de Toni Sole, el magnífico 
tanque humano de vapor de Oscar Al- 
varez Díaz y la catapulta orca de Ju- 
lián Hierro. Pero, ni que decir tiene 
que habrá nuevas contiendas entre or- 
cos y humanos y para celebrarlas uti- 
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Prueba de composición de la portada. 


lizaremos otros modelos diferentes 
entre los que nos habéis enviado. 

Nota: nos hubiera gustado dar el 
mando de nuestros orcos a Ghorkas. 
el fantástico orco creado por José Luis 
Robledo Pescador. Pero la malla que 
envió no estaba entera —faltaban pie- 
zas en los brazos—. José Luis, si quie- 
res que tu modelo aparezca en una 
próxima edición, por favor, envía una 
malla completa. 

En cada nueva edición intentaremos 
preparar cosas nuevas. Y quizá algún 
día estemos preparados para crear, 
además, una descomunal animación 
con cientos de modelos corriendo o 
batallando entre sí. 

Naturalmente todo esto también es 
aplicable a los mechs o a cualquier 
otro tema que se escoja como porta- 
da: últimamente se ha hablado bastan- 
te de preparar escenas espaciales. 


En general se prepararan es- 
cenas de uno u otro tipo se- 
gún el número de modelos 
que hayáis enviado. lo cual 
equivale también a enviar 
votos a favor de un tema da- 
do para que estudiemos si 
es posible o no llevarlo a la 
práctica como protagonista 
de la portada. 


Las escenas 

Casi todo el presente núme- 
ro constituye una pequeña 
introducción a «POV», lo 
cual no guarda demasiada 
relación con las ilustracio- 
nes empleadas. El motivo 
de esto, aparte por supuesto 
de nuestras ganas de pre- 
sentar por fin una contien- 
da virtual, es que una intro- 
ducción de este tipo sólo requiere 
Unas escenas muy sencillas que, esta- 
mos seguros, los lectores no necesi- 
tarán para entender las explicaciones. 
En lugar de esto hemos preferido 
ilustrar Rendermanía con estas esce- 
nas para mostrar lo que «POV» es ca- 
paz de hacer. 


NOTA: las escenas más complejas han re- 
querido una media de 10 minutos de parsing 
(los ficheros .inc con las mallas tienen un ta- 
maño de unos 50 Megas) y de 20 a 60 minutos 
para ser renderizadas sobre un Pentium a 150 


MHz. ¿Quién dijo que «POV» es lento? 


NOTA: Por falta de espacio, encontraréis 
dentro del fichero leedme.1xt en el directorio 
Batalla dentro de la sección Rendermanía 
en el CD-ROM de la revista, las instruccio- 
nes oportunas para manejar los ficheros que 


adjuntamos. 


e 


El Foro del Lector 


Vora importante. Podéis remitirnos vuestros trabajos o consultas, bien por carta a la dirección que 
figura en el sumario de Pemanía, o vía e-mail a rendermania.pcmaniaO hobbypress.es 


Preguntas, sugerencias 
y polémicas 


En este número, como siempre, nuestro foro es la galería de siempre 
donde podréis hallar magníficas escenas y alguna que otra animación. 
Sin embargo, este mes queremos hacer hincapié en el propio foro, es 
decir, en las cartas remitidas por los autores de estos trabajos. En ellas 
encontraréis descripciones de los procesos de creación, preguntas (a las 
que no siempre podemos contestar por falta de espacio), propuestas 


interesantes y opiniones diversas. 


Este mes nuestra primera página del foro es para Roberto (:racia, el cual sólo 
ha tardado unas dos semanas en crear su propio trasatlántico virtual. Aunque 
claramente ambientado en el “Titanic”, el “Oriental” ha sido diseñado entera- 
mente por este autor, quien ha empleado «3D Studio 4» y «Spatch» para crear el 
monumental barco que podéis ver aquí. Sin embargo, el “Oriental” aún no está 
realmente listo para su botadura ya que. como cuenta el propio Roberto en su 
carta, aún faltan hamacas, sillas y otros detalles. Algo que Roberto ya tiene pre- 
visto hacer en la animación que espera preparar próximamente. 
Hay que descubrirse ante el resultado obtenido por Roberto. El barco es muy convincente, tiene una estructura fun- 
cional dividida en cubiertas (conectadas entre sí con escaleras) y dispone también de los inevitables botes de salva- 
mento. Roberto incluso ha utilizado un modelo humano para comprobar la co- 
rrecta proporción de todos los detalles del 
“Oriental”. En fin, un barco de verdadero lu- 
Jo por el que te enviamos nuestras más sin- 
ceras felicitaciones. Confiamos que pronto 
podamos ver una animación en la que nave- 
gue por esos mares virtuales. (Nota: más de- 
talles en la carta de Roberto, en el foro). 
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El Foro del Lector 


“ar”. 


ira, MEA ADE Si queréis ver un buen 


a E combate espacial en- 


lr Ad ] tre los inolvidables 


cazas rebeldes y los 


Tie imperiales echad 
un vistazo a la magnífica animación remitida por 

. Tanto ésta como los mo- 
delos que aparecen en ella están pero que muy 
bien (sobre todo para alguien que lleva poco 
tiempo en esto). La coreografía de la batalla está 
muy lograda y las escenas donde se ve la cara 
del piloto aportan simpatía y realismo. Sin em- 
bargo, sentimos decir que el primer disco de la 


serie llegó mal y a causa de esto no hemos podi- 


Un grupo de rendermaniacos se ha unido para formar el do publicar los títulos. 
grupo con el encomiable propósito de crear En cuanto a tus preguntas. Para conocer las 
una librería de objetos de libre uso. En su carta, características del «MAX» te acensejamos el li- 
—uno de los miembros de este grupo- solicita la co- bro publicado sobre este programa por Roberto 
laboración de otros rendermaniacos y da su dirección y la Potenciano en Anaya. «<POV», por otro lado, es 
dirección e-mail de otro de los miembros. (Iñaki ha en- un trazador de rayos que emplea un lenguaje pa- 
viado también las ra modelar en lugar de una interfaz gráfica como 
dos escenas espa- la empleada por «3D Studio». No olvidéis leer la 
ciales que podéis carta de Sergio para poder ver la animación. 


ver aquí). Lo di- 
cho, una original 
iniciativa a la que 
deseamos el ma- 
yor de los éxitos. 


ha empleado a «Polyray» (el raytracer hermano de 
«POV») para crear su castillo y a «POV» y «Moray» para levantar la estupenda iglesia 
virtual que podéis ver aquí. Para la iglesia —que aún no 


está completamente acabada— Francisco ha usado tam- 


bién los famosos flares de Nathan Kopp. Sus cartas, don- 
de describe el proceso de creación de ambos edificios, son una lectura recomen- 
dable para cualquier pov-adicto. Hay que destacar la forma en que Francisco creó 
la montaña y la integró con el castillo y el truco, sencillo pero efectivo, utilizado 
para ganar tiempo con las pruebas de render. En resumen, un buen trabajo. 


Como ya hemos dicho más de una vez, la lectura de las cartas del fo- 
ro suele ser una fuente de satisfacciones para nosotros, pero esto no 
siempre es así y como ejemplo de excepción presentamos hoy la car- 
ta de Pedro J. Ladaria lindes, el cual nos ha enviado varias escenas 
creadas con «3D Studio». La pena que hemos sentido al leer tu carta 
no se debe a la decepción que sufriste al ver la portada del número 9 
(ya explicamos entonces por qué no pudimos hacer algo mejor) ni 
por tus opiniones sobre «POV», ni tampoco por tus escenas (que nos 
han gustado bastante y cuya crítica ya has hecho tú mismo). No, lo 
que nos ha fastidiado es el párrafo G de tu apartado de consejos: ¿Có- 
mo puedes hablar así de la piratería? Es cierto que mucha gente tiene 


versiones piratas de programas de render. Esto no es algo especial- 


mente dañino porque se trata de aficionados que no van a dedicarse 
profesionalmente a la infografía o que van a aprender antes de dedi- 
carse legalmente a ella (y por tanto a comprar). Pero de comprender esto a recomendar la compra de CD piratas media un 
abismo. Nosotros hemos comprobado el daño que la piratería hace a la producción de software. Sabemos que... 
1) No importa lo barato que pueda ser un programa. Existe un alto porcentaje de gente que siempre preferirá hacerse con una 
copia pirata. (¿Se sentirán más listos así?). 2) Hay muchos programadores de talento que se desaniman porque los beneficios 
de su duro trabajo no están garantizados por culpa de la piratería. Y no nos referimos aquí a programas caros sino a otros que 
están teóricamente al alcance de cualquier bolsillo y que bastante gente prefiere encontrar en alguno de esos CD piratas que 
mencionas. (Porque en ellos vienen muchos programas por el precio de uno. ¿No?) 
Espero que recapacites sobre lo que has dicho y para terminar solo te diremos dos cosas: 
¿Cuánto habrías tardado tú en renderizar una imagen coro la del número 14, por ejemplo? Con «POV» una imagen de este ti- 
po a 800*600 puede tardar de 30 a 45 minutos. La verdad es que sí sabemos algo de «MAX» pero las páginas de Rendermanía 
están dedicadas a programas share o free y a versiones libres de programas comerciales porque están al alcance de todos. ¿Y 


cuánto sabes tú de «POV» para hablar así de él? 


Felipe Cañizares es un nuevo povmaníaco que tan solo 
llevaba dos semanas con «POV» cuando envío estas dos 
imágenes. Para él un 

par de consejos: 

1) El libro que tienes no 

trata de la versión 3.0 

pero empóllate como 

sea las sentencias de 

programación de POV. 

¡Tus escenas ganarán 

mucho con ellas! 

2) Procura emplear los 


Jordi y Alber: son otro par de rendermaníacos adep- 
tos a «3D Studio 4» y a «MAX». Nos ha gustado el 


anuncio de la pasta dentífrica y también las originales 


efectos de «POV» sólo cuando tengas listos todos los de- 


talles de la escena. Ganarás tiempo (y esto también va 


por las áreas de luz, aunque no sean ningún efecto). 


escenas con las poses futbolísticas. La cámara, la luz y 
las texturas son correctas pero creemos que aún debe- Tomo nota de tu sugerencia de las ciudades futuristas y 


ríais ejercitaros más con el modelado. las batallas espaciales para las portadas. 
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De Mario Prats Sánchez nos llegan dos 
cartas. En la primera veremos al Arachno, 
un original mech en forma de araña prepara- 
do para todas las vicisitudes de la guerra vir- 
tual moderna. El modelo creado con Imagi- 
ne y renderizado desde POV ha llegado 
demasiado tarde para la primera portada de 
mechs pero no temas. ¡Habrá mas! Arach- 
no nos ha gustado mucho y tan solo cambia- 
ría la forma de los pies y el valor de reflec- 
tion, el cual nos parece alto. En cuanto a lo 
que dices de la memoria, no hay forma de 
saber a priori el tamaño que tendrá el .inc 
resultante de una conversión pero sí de saber 
la cantidad de RAM que usa «POV», ya que 
te lo dice el propio programa en la pantalla 
de estadísticas al acabar el render. 

En su segunda carta (en el directorio se- 
gunda) Mario nos cuenta su paso a «MAX» 
y nos envía escenas con un castillo que pa- 
rece de juguete. Esto se debe a la textura 


empleada y a la simplificación de algunos 


detalles. Por ello creemos que las escenas, 
resultonas gracias a las múltiples luces, ha- 
brían ganado si hubieras puesto el castillo 
sobre una mesa con otros juguetes. aunque 
esta idea tampoco es muy original. 

Por último, pasaremos tu sugerencia sobre 


los plug-ins a redacción. 


Antonio Rodríguez Gregore» nos envía un estupendo Mech cre- 
ado con «MAX» e «Imagine». Antonio ha enviado al Nay1 001-£x 
desglosado en partes para que nos sea más fácil prepararlo para 
«POV» con vistas a la portada de mechs (¡gracias, lo utilizare- 
mos!) y también apunta una estupenda idea, que los propios lec- 
tores creen sus propias batallitas empleando mechs de otros auto- 
res. Así, en cada enfrentamiento, cada parte podría realizar una 
escena con su mech y el del contrincante, ganando el autor que 
hubiese preparado la escena más resultona. De momento Antonio 


ha desafiado ya a los her- 
manos Oscar y Alberto 
Otero Leal y a Benjamin 
Albares Moreno. ¿Al- 
guien recoge el guante? 
En cuanto al Nayi, se 
trata de un buen modelo 
al que quizá le falte un 
poco de detalle. Nos ha 
gustado más tu escena 
habit.jpg. que es una de 
las mejores habitaciones virtuales que han pasado por aquí (por 


la luz, las texturas, la disposición del cuarto, etc.) 


Raul Gomez Cardoso nos ha enviado unas simpáticas criaturi- 
llas virtuales creadas con «3D Studio 4». Por un lado está un or- 
co-ogro y por atro una especie de alien-perro. Bien. no vamos a 
criticar tu obra pero te daremos un par de consejillos: 
1) Hasta que no tengas más práctica en el modelado de formas 
orgánicas procura que tus modelos antropomórficos queden me- 
nos desnudos. Podrías, por ejemplo, haberle puesto una armadu- 
ra al orco con lo cual 
habrías Obviado la rea- 
lización de ciertas par- 
tes difíciles. La verdad 
es que el cuerpo de tu 
modelo parece casi una 
armadura. Tan solo ha- 
brías tenido que cam- 
biar el color verde del 
cuerpo y añadir algunas piezas más para que pareciese que el 
monstruo estaba dentro de una armadura. 2) Respecto a tus difi- 
cultades con «3D Studio 4» te recomendamos que te compres al- 
gún libro sobre el tema. Te ahorrarás muchos sufrimientos. 


